放送ネットワークを通じてファイルのサイズを推定する装置及び方法

专利摘要:
受信しようとするコンテンツのサイズを、そのデータの実際の送信前に推定する装置及び方法は、電子サービス・ガイド（ＥＳＧ）情報を利用する。ＥＳＧ情報は、クライアント・デバイスが、ファイル供給源による実際のファイルの送信前に、そのファイルの情報を得る際に役立つ。これにより、ユーザ・デバイスの電源をより効率的に管理でき、ユーザの介入を必要とすることなく、ユーザが興味を持つ特定のファイルを取得（すなわち、ダウンロード）して記憶するのに必要な電力資源を消費する前に、ユーザ・デバイスに記憶すべきか否かの決定を行う機能を、ユーザに提供できる。
公开号:JP2011507127A
申请号:JP2010539394
申请日:2007-12-18
公开日:2011-03-03
发明作者:エム． アンスル，シエミモン；アンソニー キヤンパナ，デイビツド；スリドハー，アビナツシユ；マクドナルド ボイス，ジル
申请人:トムソン ライセンシングＴｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ；
IPC主号:G06F12-00

专利说明:

[0001] 本発明は、放送ネットワークに関し、より詳しくは、ファイルのサイズをファイルの受信前に推定することに関する。]
背景技術

[0002] 例えばＤＶＢ−Ｈのような放送技術により、低電力の携帯可能なクライアント・デバイスへのデータの配信が可能になり、これにより、コンテンツのオン・デマンド・サービスが可能になっている。このようなサービスでは、コンテンツは、クライアントにおいて継続的に受信され、エンド・ユーザは、そのコンテンツをその場であるいは後で消費（視聴）できる。場合によっては、記憶すべきコンテンツの量が、クライアントの記憶容量により制限されてしまう。サービスがコンテンツの更新を頻繁に行う場合、受信データの記憶と置き換えを迅速に行えることが望ましい。そのようなサービスにおいては、受信しようとしているコンテンツのサイズを、実際のデータ送信の前に推定することが、既に記憶されているコンテンツを置き換える際、あるいは、今後どのコンテンツを記憶すべきかを決定する際に役立つことがある。]
[0003] 本原理の一態様によれば、放送ネットワークにおける通信チャネルを通じたファイル・サイズ推定方法は、放送スケジュール情報を用いて、ファイルのサイズを、ファイルを実際に受信する前に推定することと、ファイルを受信して記憶すべきか否かを、クライアント・デバイスへファイルを自動的に及び／又はユーザの介入を必要とすることなくダウンロードする前に、決定することとを含む。この決定は、クライアント・デバイス上のユーザ・プロファイル内に記憶されているユーザの好みに基づく。この方法は、通信チャネルの帯域幅を特定することを更に含むことが可能である。]
[0004] ファイル・サイズの推定は、放送スケジュールから当該ファイルの開始時刻と終了時刻とを求めることによって行うことが可能である。別の実施形態において、ファイル・サイズの推定は、サービス・プロバイダから得られる、ファイルに関する電子サービス・ガイド（ＥＳＧ）情報を用いる。]
[0005] 帯域幅の特定は、通信チャネルの帯域幅を推定することによって、あるいは、通信チャネルの帯域幅についての既知の値を得ることによって、行うことが可能である。]
[0006] 本原理の他の態様による装置は、メモリを内蔵するモバイル・クライアント・デバイスを含んでおり、モバイル・クライアント・デバイスは、放送スケジュール情報を用いてファイル・サイズをファイルを実際に受信する前に推定するように構成されており、且つ、ファイルを受信して記憶すべきか否かを、ファイルをデバイスのメモリに自動的に及び／又はユーザの介入を必要とすることなくダウンロードする前に、自動的に決定するように構成されている。]
[0007] モバイル・クライアント・デバイスは、更に、モバイル・デバイスへファイルを送信する通信チャネルの帯域幅を特定するように構成されている。]
[0008] クライアント・デバイスのメモリに記憶されたユーザ・プロファイルは、ユーザによる介入を必要とすることなく、クライアント・デバイスが上記の自動的な決定を行うことを可能にする。]
[0009] 本原理の他の態様による装置は、メモリを内蔵するモバイル・クライアント・デバイスを含む。メモリは、モバイル・クライアント・デバイスを動作させる際に使用される読み取り可能なプログラム・コードが組み込まれているコンピュータ・プログラム・プロダクトを含む。プログラム・プロダクトは、放送スケジュール情報を用いて、ファイルのサイズをファイルを実際に受信する前に推定するプログラム・コードと、ファイルを受信して記憶するか否かを、ファイルをモバイル・クライアント・デバイスにユーザの介入を必要とすることなくダウンロード前に決定するプログラム・コードとを含む。クライアント・デバイスは、推定されたファイル・サイズを用いて、クライアント・デバイスにおける記憶スペースの制限を定めるプログラム・コードを更に含む。この決定は、クライアント・デバイスのメモリに記憶されたユーザ・プロファイル内に記憶されている好みに基づいて行われる。]
[0010] 本原理のその他の実施形態及び特徴は、各添付図面を参照しつつ読まれるべき以下の詳細な説明から明らかになるであろう。なお、各図面は、説明の目的のためのみに作成されたものであり、本原理の範囲を確定するものとして作成されたものではない。本原理の範囲については、特許請求の範囲を参照されたい。更に、各図面は、必ずしも、一定の率で縮尺又は拡大した訳ではなく、特に断りのない限り、本明細書に記載の各構造及び手順を単に概念的に例示したものに過ぎない。]
図面の簡単な説明

[0011] 各図面において、同一の参照番号は、類似の構成部分を示している。
既知の例による双方向放送ネットワークのシナリオのブロック図である。
既知の例による片方向放送ネットワークのブロック図である。
クリップと、クリップが放送される時点とを表す図である。
放送されるクリップＡとクライアント・デバイス内に記憶された数個のクリップとを表した図である。
本原理の一実施形態によるファイル・サイズ推定方法のフローチャートである。
本原理の一実施形態による方法のブロック図である。
本原理の他の実施形態によるファイル・サイズ推定方法のフローチャートである。]
実施例

[0012] 任意のチャネルの瞬時帯域幅を推定する方法が幾つか知られている。この推定は、通常、双方向ポイント・ツー・ポイントのネットワークにおいて、既知量のデータを取得するのに要する時間を測定することによって行われる。図１には、双方向ポイント・ツー・ポイントのネットワーク１００が例示されており、そのネットワークにおいて、サーバ１０２とクライアント１０６とが、ネットワーク１０４を介して互いに双方向通信可能になっている。] 図１
[0013] 殆どの双方向クライアント／サーバ・ネットワークのアーキテクチャでは、クライアントが、既知量のデータを要求し、サーバとの間で送受信する一連のネットワーク・パケットを介してデータ送信の開始時刻と終了時刻を記録してチャネル容量を推定する。]
[0014] 図２には、片方向クライアント／サーバ・ネットワークのアーキテクチャ２００が例示されており、このアーキテクチャにおいて、サーバ２０２が１つ以上のクライアント２０４Ａ〜２０４Ｃにデータを送信する。] 図２
[0015] ファイルの配信は、ＦＬＵＴＥ（Ｆｉｌｅ＿Ｄｅｌｉｖｅｒｙ＿ｏｖｅｒ＿Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ＿Ｔｒａｎｓｐｏｒｔ）プロトコルを用いて行うことができる。ＦＬＵＴＥは、マルチキャスト・ファイル配信用プロトコルであり、片方向ネットワークを介してデータあるいはコンテンツを送信するのに使用できる。クライアントは、任意の時点で流れているデータの量をモニタして、この情報によりチャネル容量を推定できる。チャネル容量が一定である環境では、この測定は一度だけ行えばよい。容量が変動するチャネルの場合、チャネル容量（すなわち、帯域幅）のベスト・エフォートを維持し、かつ常時更新することができる。]
[0016] 個人用放送ビデオ・システムは、ネットワークの帯域幅を効率良く使用し、かつ受信装置のバッテリの使用を最小限に抑えつつ、個人用の簡易ユーザ・インタフェースを提供している。受信装置におけるユーザ・プロファイルは、ユーザの興味の対象を示す。放送される個別の各クリップは、電子サービス・ガイド（ＥＳＧ）で送られる、例えばキーワードのようなフレキシブル・メタデータ・タグと対応付けられている。ＥＳＧには、放送予定のテレビジョン番組についての情報が含まれており、一般的に、個別番組についての記述データ、すなわちメタデータ、例えば、その番組の名称、概要（あらすじ）、俳優、ディレクタ等、更に、放送の予定日時、継続時間、及び、チャネルが含まれている。]
[0017] ＤＶＢ−ＣＢＭＳ規格は、ＤＶＢ−Ｈを使用して、例えば圧縮されたビデオ・ファイル又はオーディオ・ファイルのようなマルチメディア・コンテンツ・ファイルの放送用サービスを可能にしている。ＤＶＢ−ＨのＥＳＧは規格化されたＥＳＧを提供しており、この規格化されたＥＳＧは、ＴＶ−Ａｎｙｔｉｍｅプログラミング、すなわち、Ｏｎ−ｄｅｍａｎｄプログラミングに準拠している。ＤＶＢ−ＨのＥＳＧでは、個々のコンテンツが、コンテンツ・フラグメントのＣｏｎｔｅｎｔＩＤの属性によって固有に識別される。]
[0018] 個人用放送ビデオ・システムのサービスが提供される場合、コンテンツは、継続的に放送され、クライアントの好みに基づいて受信されて記憶される。しかし、このような場合、クライアントは、電源が常にオンになる傾向があり、従って、電力使用が非効率的になってしまう。好みのコンテンツを受信するときにだけクライアントが電源をオンにすれば、電力管理はより効率的になる。しかし、これを行うには、クライアントは、どのコンテンツを自己の記憶装置の限度に基づいて保存できるかを、コンテンツの実際の放送前に決定する必要がある。本原理の一実施形態によれば、この決定はクライアント・デバイス内に記憶されたユーザ・プロファイルの好みに従って行われ、その結果、ユーザによる介入が不要になる。]
[0019] ＤＶＢ−ＨのＥＳＧは、Ｓｔｏｒａｇｅ識別子のもとで、ＦｉｌｅＤｏｗｎｌｏａｄＣｏｍｐｏｎｅｎｔＣｈａｒａｃｔｅｒｉｓｔｉｃという名称のＣｏｍｐｏｎｅｎｔＣｈａｒａｃｔｅｒｉｓｔｉｃタイプのＡｃｑｕｉｓｉｔｉｏｎフラグメントにおけるファイル・サイズ・パラメータの使用を公表している。しかし、これは、メガバイト単位のファイル・サイズを示すのみであり、この精度は、コンテンツを実際の放送の前に予め通知するのには不十分である。]
[0020] 上述したように、片方向ネットワーク、すなわち、放送ネットワークでは、クライアントからのフィードバックが無い。クライアントは、放送されるデータを受信するだけである。このようなシナリオでは、クライアントは、データ・パケットを受動的にモニタすることによって、帯域幅を推定できる。これから放送されるコンテンツのファイル・サイズを推定するためには、チャネルの帯域幅の推定値を求める必要がある。これは、ある期間に亘ってサンプリングされた帯域幅の統計表、あるいは、その他の任意の帯域幅の推定方法を用いて行うことができる。]
[0021] 一例として、帯域幅の推定は、Ｓｅｓｓｉｏｎ＿Ｄｅｓｃｒｉｐｔｉｏｎ＿Ｐｒｏｔｏｃｏｌ（ＳＤＰ）ファイルに規定された「ｂ＝」識別子を用いて行える。このＳＤＰファイルには、コンテンツの取得に関連する一組の識別子が含まれている。]
[0022] 他の例では、クライアントは、パケット送信の開始をタイムスタンプにより記録し、一定期間後に、データがどれだけ受信されたかを求めることができる。これは、クライアントがチャネルの帯域幅を推定するのに役立つ。ここでは、チャネルの帯域幅＝単位時間当たりの受信バイト数である。]
[0023] 他の帯域幅推定方法は、クライアントに対するサーバ提供データを用いて行われる。例えば、ＤＶＢ−ＨのＥＳＧ仕様を用いることによって、Ｓｔｏｒａｇｅ識別子を、これから放送されるコンテンツ・ファイルのファイル・サイズの大まかな推定値として使用できる。この大まかな推定値と、クライアント・デバイスに既に受信されたスケジュールＥＳＧフラグメントから得られた放送の開始時点及び終了時点とを用いて、初期の期間に亘って、帯域幅を推定できる。これは、特に、チャネルの帯域幅が変動する場合に有効である。クライアント・デバイスは、この方法を用いて、概算の帯域幅を推定できる。また、クライアントは、この方法を用いて、推定におけるエラーも算出できる。例えば、ファイル全体が一旦ダウンロードされると、そのファイルの実際のサイズが判明し、これを用いて帯域幅を再算定でき、従って、その後の推定がより正確になるように各推定パラメータを調節できる。]
[0024] ファイル・ダウンロード・サービスは、ダウンロード用コンテンツをファイルの形態で提供するサービスと定義してもよい。これらのファイルは、受信機アプリケーションで消費（処理）されてユーザに提示される。このサービスのプロバイダは、クライアント・デバイスの電力及び記憶装置のニーズについて配慮する必要がある。コンテンツは継続的に放送されており、新たなコンテンツがクライアント・デバイスに記憶される一方、古いコンテンツがそれに置き換えられる。古いコンテンツの置き換えは、電力と共に時間にも配慮する必要がある。クライアント・デバイスは、コンテンツのファイル・サイズを事前に知っていれば、デバイス上のコンテンツを置き換える際にインテリジェントな選択を行え、それと同時に、受信のためのより優れた電力管理を行える。]
[0025] 一旦、帯域幅が推定されると、これから放送されるコンテンツのサイズが推定できる。]
[0026] 図３及び図４を参照し、クリップＡが近い将来の時刻Ｔ１に放送され、クライアント・デバイス４００が、自己のメモリ領域４０２に記憶済みのファイル・コンテンツ・クリップＢ，Ｃ及びＤを含んでいるシナリオを考える。クライアントは、先に受信した送信データから得たスケジュールＥＳＧ情報をパース（解析）することによって、クリップＡの放送時間を知ることができる。受信機（クライアント・デバイス４００）は、クリップＡを記憶すべきか否かを決定する必要がある。本例の説明の便宜上、クリップＢ，Ｃ及びＤが共にデバイス上の記憶スペースのかなりの割合を占有していると仮定する。本例におけるメモリ領域４０２は、コンテンツ及び／又はクライアント・デバイスの動作に関するプログラミング情報を記憶するための任意のタイプの既知のメモリであってもよい。一実施形態では、メモリ４０２には、本明細書に開示する本原理の各方法及び各処理を実施するプログラミングが含まれている。] 図３ 図４
[0027] クライアント・デバイス４００は、クリップＡのサイズを用いて、そのクリップを記憶するかどうかを決定する。クライアントは、クリップＡの推定ファイル・サイズを用いて、クリップＡを記憶するか否かを事前に決定できる。例えば、クライアント・デバイスは、クリップＡの実際のサイズを知ることなく、時刻Ｔ１で電源がオンになり、クリップＡの全てを受信する。ファイルのダウンロード完了（時刻Ｔ２）の後に、そのクリップのファイル・サイズが判る。クライアント・デバイスは、このファイル・サイズとクリップＡのその他の特徴（例えば、キーワード等）に基づいて、クリップＡを記憶する一方、既存のコンテンツ（クリップＢ、Ｃ及びＤ）の一部をこれに置き換えるか、あるいは、クリップＡを廃棄することができる。クリップＡを受信する電力を消費した後にクリップＡを廃棄することは、電力使用の観点から浪費であり、バッテリ寿命を減らすことになる。]
[0028] クライアント・デバイスは、クリップＡの推定ファイル・サイズを用いて、クリップＡを記憶すべきか否かを事前に決定できる。デバイスは、クリップＡの記憶が不要であると決定した場合、そのクリップの放送期間中、電源をオンにする必要はなく、従って、その期間の間、自己の受信処理部の電源を切ることによって、デバイスの電源使用を低減できる。]
[0029] 図５には、コンテンツを記憶するか否かに関係なく、受信モジュール（すなわち、クライアント・デバイス）の電源をオンにする必要がある方法５００が示されている。その必要の主たる理由は、受信モジュールが、ＥＳＧスケジュールの受信（５０２）直後に起動される（５０４）ためである。コンテンツが受信され（５０６）、コンテンツの受信が終了したか否かが判定される（５０８）。コンテンツが完全に受信されると、ダウンロード済みサイズが算出され（５１０）、クライアント・デバイスが、コンテンツを記憶するか否かを決定する（５１２）。記憶しない場合、受信コンテンツは削除され（５１４）、デバイスはスケジュール受信状態に戻る。記憶する場合、受信コンテンツは記憶され（５１６）、デバイスはスケジュール受信状態に戻る。上述のように、この方法は、常に、クライアント・デバイス、すなわちユーザ・デバイスの電源をオンにして受信モード状態にする必要があり、従って、特にコンテンツを完全に受信した後に、ユーザが受信したコンテンツを削除する決定をした場合に、バッテリの電力使用が非効率となり得る。] 図５
[0030] 図６Ａには、本原理の一実施形態による方法６００が示されている。この方法では、クライアント・デバイスにおける電源使用がより効率的に管理される。先ず、通信チャネルの帯域幅が特定される（６０２）。上述したように、この特定は、実際のＢＷ（帯域幅）であってもよいし、既知のＢＷ（帯域幅）であってもよいし、あるいは、任意の適切な既知のチャネル帯域幅推定方法を用いて推定してもよい。一旦、帯域幅が判ると、先に受信したＥＳＧ情報を用いて、ファイル（コンテンツ）のサイズが推定できる（６０４）。ファイル・サイズが特定あるいは推定されると、スマート・クライアント・デバイスは、ユーザの介入を必要とすることなく、クライアント・デバイスにそのファイル（コンテンツ）をダウンロード（記憶）すべきか否かを決定できる（６０６）。この決定は、ユーザによってクライアント・デバイスのメモリに記憶されたユーザ・プロファイルに事前に設定されたユーザの好みに基づいて行われる。] 図６Ａ
[0031] 図６Ｂには、図６Ａのステップ６０４及び６０６の更に詳しいブロック図が示されている。先ず、スケジュールＥＳＧが受信される（６０８）。受信済みスケジュール・リストが、新たな今後のコンテンツ放送について反復適用されるか、あるいは、新たな今後のコンテンツ放送について見直される（６１０）。次に、ファイル・サイズが、放送の開始時間及び終了時間を用いて、スケジュール情報から算出（すなわち、推定）される（６１２）。この情報により、クライアント・デバイスは、コンテンツを記憶すべきか否かを決定できる（６０６）。クライアント・デバイスが記憶すべきであると決定すると、受信モジュールの電源がオンにされて、新たなコンテンツの受信が開始される（６１４）。クライアント・デバイスがそのコンテンツを受信し始めて（６１６）、そのコンテンツの全部が受信されると（６１８）、そのコンテンツが記憶され（６２０）、本プロセスは、最初に戻る。クライアント・デバイスは、本プロセスが完了すると、自動的に電源が落とされる。一般的に、クライアント・デバイスはアクティブでない場合には、電源が落とされる。クライアント・デバイスは、アクティブ状態にある場合、自己の受信処理ハードウェア構成部の電源を落とす。] 図６Ａ 図６Ｂ
[0032] 本原理の一実施形態によれば、帯域幅が変動するチャネル、あるいは、帯域幅が一定であるチャネルについてのファイル・サイズの算出における各ステップは、ＥＳＧから得られ、次の通りである。
放送の継続時間＝放送終了時刻（EndBroadcastTime）−放送開始時刻（StartBroadcastTime）
ファイル・サイズ＝（チャネルの帯域幅）×（放送の継続時間）]
[0033] 本原理は、ハードウェア、ソフトウェア、ファームウェア、特定用途プロセッサ、あるいは、それらの組み合わせの様々な形態で実施できることを理解されたい。好ましくは、本原理は、ハードウェアとソフトウェアとの組み合わせとして実施される。更に、ソフトウェアは、プログラム記憶装置に実装されたアプリケーション・プログラムとして実施されることが好ましい。アプリケーション・プログラムは、任意の適切なアーキテクチャを備えたマシンにアップロードして、そのマシンにより実行できる。好ましくは、そのマシンは、１又は２つ以上の中央処理装置（ＣＰＵ）、ランダム・アクセス・メモリ（ＲＡＭ）、及び入力／出力（Ｉ／Ｏ）インタフェース等のハードウェアを有するコンピュータ・プラットフォーム上に実装される。コンピュータ・プラットフォームには、オペレーティング・システムとマイクロインストラクション・コードが含まれていてもよい。本明細書に記載された種々の処理と機能は、オペレーティング・システムを介して実行されるマイクロインストラクション・コードの一部、あるいは、アプリケーション・プログラムの一部、あるいは、それらの組み合わせであってもよい。更に、増設データ記憶装置、及び印刷装置等の種々のその他の周辺機器をコンピュータ・プラットフォームに接続してもよい。]
[0034] 更に、添付図面に示された各構成システム・コンポーネント及び方法ステップの一部はソフトウェアの形態で実施されることが望ましいため、システムのコンポーネント相互間、あるいは、プロセスのステップ相互間の実際の接続は、本原理がプログラムされる態様によって異なり得ることを理解されたい。本明細書に記載された各開示事項により、当業者であれば、本原理のような、及び、同様な実施形態、あるいは、同様なコンフィギュレーション（環境設定、機器構成等）を考案できるであろう。]

权利要求:

請求項1
スケジュール情報を用いて、ファイルのサイズを該ファイルの受信前に推定するステップ（６０４）を含む、ファイル・サイズ推定方法。
請求項2
前記ファイルのサイズの推定に応答して、前記ファイルを受信するか否かを決定するステップ（６０８）を更に含む、請求項１記載の方法。
請求項3
通信チャネルの帯域幅を特定するステップ（６０２）を更に含む、請求項１記載の方法。
請求項4
前記推定するステップ（６０４）は、スケジュールから前記ファイルの開始時刻と終了時刻とを求めることを更に含む、請求項１記載の方法。
請求項5
前記推定されたファイルのサイズを用いて、クライアント・デバイスにおける記憶スペースの制限を定めることを更に含む、請求項２記載の方法。
請求項6
前記ファイルのサイズの推定に応答して、前記ファイルを記憶するか否かを決定することを更に含む、請求項２記載の方法。
請求項7
前記帯域幅を特定するステップは、前記通信チャネルの前記帯域幅を推定することによって行われる、請求項３記載の方法。
請求項8
前記帯域幅を特定するステップは、前記通信チャネルの前記帯域幅についての既知の値を得ることによって行われる、請求項３記載の方法。
請求項9
前記推定することは、前記通信チャネルを通じて受信されたパケットの量を、ある期間の間モニタすることを更に含む、請求項７記載の方法。
請求項10
前記決定するステップが、クライアント・デバイスに記憶されたユーザ・プロファイルに従って行われる、請求項２記載の方法。
請求項11
前記推定するステップ（６０４）は、前記ファイルに関する電子サービス・ガイド（ＥＳＧ）情報を利用することを更に含む、請求項１記載の方法。
請求項12
メモリ（４０２）を有するモバイル・クライアント・デバイス（４００）であって、スケジュール情報を用いて、ファイルのサイズを該ファイルの受信前に推定する動作を行う前記モバイル・クライアント・デバイスを含む装置。
請求項13
前記モバイル・クライアント・デバイスは、前記ファイルのサイズの推定に応答して、前記ファイルを受信するか否かを決定する動作を更に行う、請求項１２記載の装置。
請求項14
前記モバイル・クライアント・デバイスは、前記ファイルを前記モバイル・デバイスへ送信する通信チャネルの帯域幅を定める動作を更に行う、請求項１２記載の装置。
請求項15
前記クライアント・デバイスの前記メモリに記憶されており、前記モバイル・クライアント・デバイスが前記ファイルを受信することを決定することを可能にするユーザ・プロファイルを更に含む、請求項１３記載の装置。
請求項16
モバイル・クライアント・デバイスを動作させる際に使用される読み取り可能なプログラム・コードが組み込まれているコンピュータ・プログラム・プロダクトを有するメモリを内蔵する前記モバイル・クライアント・デバイスを含む装置であって、前記プログラム・プロダクトが、放送スケジュール情報を用いて、ファイルのサイズを該ファイルの受信前に推定するプログラム・コードと、前記ファイルのサイズの推定に応答して、前記ファイルを受信するか否かを決定するプログラム・コードと、を含む、前記装置。
請求項17
前記プログラム・プロダクトは、前記ファイルを前記モバイル・デバイスへ送信する通信チャネルの帯域幅を特定するプログラム・コードを更に含む、請求項１４記載の装置。
請求項18
前記プログラム・プロダクトは、前記推定されたファイルのサイズを用いて、前記クライアント・デバイスにおける記憶スペースの制限を定めるプログラム・コードを更に含む、請求項１４記載の装置。
請求項19
前記通信チャネルの帯域幅を特定する前記プログラム・コードは、前記通信チャネルの前記帯域幅を推定するプログラム・コードを更に含む、請求項１５記載の装置。
請求項20
前記帯域幅を推定する前記プログラム・コードは、前記通信チャネルを通じて受信されたパケットの量を、ある期間の間モニタするプログラム・コードを更に含む、請求項１７記載の装置。